Instant token issuance system

ABSTRACT

A user can request provisioning of account information for an account to a plurality of resource providing entities. The account may be a new or existing account issued by an authorization computer. The authorization computer may prompt the user to select one or more resource providing entities to which to provision a token associated with the account. Processor server computer may then tokenize the account information associated with the account by determining a token for each resource providing entity selected by the user. In some cases, a token may be provisioned to an already existing account or profile (e.g., account on file) associated with a resource providing entity. In other cases, an account or profile associated with a resource providing entity may not yet exist and thus may be created before a token may be provisioned. Subsequently, the user may utilize provisioned tokens to conduct transactions.

CROSS-REFERENCES TO RELATED APPLICATIONS

This application is a non-provisional of and claims the benefit ofpriority to U.S. Provisional Application No. 62/242,068, filed Oct. 15,2015, and U.S. Provisional Application No. 62/242,074, filed Oct. 15,2015, which are hereby incorporated by reference in its entirety for allpurposes.

BACKGROUND

Users often manage multiple digital accounts associated with variousentities. For example, these accounts may be associated with a varietyof resource providing entities, such as merchants, digital walletproviders, and service providers. In some cases, a user may add a cardaccount to these digital accounts to conduct transactions. Typically,the user may have to provide their card account information to each ofthe corresponding resource providing entities separately beforeconducting the transactions. This is cumbersome, since the user has toperform redundant steps of inputting the same card account information.Additionally, since each resource provider may run a different platform,the input process is not smooth and timely.

Furthermore, this process of adding a card account to digital accountsis even more cumbersome when the card account is for a new card. When auser applies for a card account, such as for a credit card, there istypically a delay until the user can utilize the card for transactions.For example, the user typically may wait until the card is made onplastic and shipped to the user, which can take at least five to sevendays. This delay limits the user's ability to use the card. In addition,once the card is approved, if the user wishes to add their card accountto other digital accounts, they need to add account information for thecard manually for each digital account. It would be desirable to providethe user with the ability to use the new card as soon as possible.

Embodiments of the invention address this and other problems,individually and collectively.

BRIEF SUMMARY

Embodiments of the invention relate to systems and methods forprovisioning account information to resource providing entities anddevices. In some cases, the account information may be for an accountthat already exists or a new account requested by a user. Embodiments ofthe invention enable the user to control, through an issuer application(or a third party token portal), to which resource providing entities(e.g., merchants, digital wallet providers, service providers, etc.) theaccount information is provisioned. In some embodiments, the accountinformation may include a tokenized card account information associatedwith a card account. In some cases, the token may also be provisioned toother devices (e.g., mobile device, tablet, wearable devices, etc.)indicated by the user. The devices may have a secure element or may becloud-based. Embodiments of the invention make possible in-appprovisioning of the card onto the user's device.

According to one embodiment of the invention, a server computer canperform a method. The server computer may send a list of participatingresource providing entities to an authorization computer. Theauthorization computer may prompt a user operating a user device to makea selection from the list of participating resource providing entities.The server can then receive a selection of one or more resourceproviding entities from the participating resource providing entitiesand can receive a request to issue tokens associated with an account ofthe user for the one or more resource providing entities. For each ofthe one or more resource providing entities, the server computer candetermine a token associated with the account of the user and can sendthe token to a resource providing entity computer associated with theresource providing entity, wherein the user conducts a transaction withthe resource providing entity using the token.

The account may be a new account or an existing account. When theaccount is a new account, the server computer can receive accountinformation associated with the account from the authorization computer.When the account is an existing account, the server computer canretrieve the account information associated with the account.

In some embodiments, the server computer can perform authenticationprocesses. For each of the plurality of participating resource providingentities selected by the user, the server computer can prompt the userfor authentication information for the participating resource providingentity and can send the authentication information to the participatingresource providing entity. In some cases, the authentication informationmay be utilized to generate a new account for the user associated withthe participating resource providing entity.

In some embodiments, the server computer can further determine anauthentication method supported by the authorization computer. For eachof the list of participating resource providing entities, the servercomputer can also determine an authentication method supported by theparticipating resource providing entity and can compare theauthentication method supported by the participating resource providingentity and the authentication method supported by the authorizationcomputer. Upon determining that the compared authentication methodsmatch, the server computer can include the participating resourceproviding entity in the list of participating resource providingentities.

In some embodiments, the server computer can determine that at least oneof the participating resource providing entities has an account on filefor the user. The server computer can send, to the authorizationcomputer, information indicating the at least one participating resourceproviding entity with which the user has the account on file. In somecases, the selection of the one or more resource providing entities bythe user may include a participating resource providing entity that hasan account on file for the user. In some cases, the user may furtherconduct the transaction using the account on file.

In some embodiments, the server computer can generate one or more links.In some implementations, the server computer may generate a link routedto the server computer and can send the link to the authorizationcomputer. The user may activate the link using the user device after theauthorization computer prompts the user. In some implementation, theserver computer can generate a plurality of links routed to theplurality of resource providing entities and can send the plurality oflinks to the authorization computer. The user may activate the pluralityof links using the user device after the authorization computer promptsthe user.

Embodiments of the invention are further directed to a server computercomprising a processor and a computer readable medium. The computerreadable medium can be coupled to the processor and can comprise code,executable by the processor, for implementing any of the methodsdescribed herein.

These and other embodiments of the invention are described in furtherdetail below.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 shows an exemplary flow diagram of a method according toembodiments of the present invention.

FIG. 2 shows an exemplary user interface according to embodiments of thepresent invention.

FIG. 3 shows an exemplary user interface according to embodiments of thepresent invention.

FIG. 4 shows a block diagram of an exemplary system according toembodiments of the present invention.

FIG. 5 shows a block diagram of an exemplary system according toembodiments of the present invention.

FIG. 6 shows an exemplary flow diagram of a method according toembodiments of the present invention.

FIG. 7 shows a block diagram of an exemplary system according toembodiments of the present invention.

FIG. 8 shows an exemplary flow diagram of a method according toembodiments of the present invention.

FIG. 9 shows a flowchart of a method for enabling a user immediate cardaccess upon approval and token provisioning to account on file merchantsaccording to embodiments of the present invention.

FIG. 10 shows an exemplary flowchart of a method for enabling a userimmediate card access upon approval according to embodiments of thepresent invention.

FIG. 11 shows an exemplary flowchart of a method for enabling a userimmediate card access upon approval according to embodiments of thepresent invention.

FIG. 12 shows an exemplary flowchart of a method for enabling a userimmediate card access upon approval according to embodiments of thepresent invention.

DETAILED DESCRIPTION

Embodiments of the invention relate to account information that can beprovisioned to resource providing entities and devices. In someembodiments, the account information may be instantly issued to a user.For example, when the user applies for a new payment card with anauthorizing entity using a user device, the user can be approved for thenew payment card. Subsequently, tokens associated with the new paymentcard can be provisioned to the user device as well as to resourceproviding entities selected by the user. In other embodiments, tokensassociated with the new payment card may be created at a later timefollowing issuance of the card. Hence, embodiments of the invention arenot limited to instant issuance of cards.

Additional steps may be performed to provide the new payment cardaccount number or token associated with the new payment account numberto account on file (e.g., card on file) merchants. Embodiments of theinvention enable the user to control, through an issuer application (ora third party token portal), to which resource providing entities (e.g.,merchants, digital wallet providers, service providers, etc.) the newlyissued card's token is provisioned. In some embodiments, the token mayalso be provisioned to other devices (e.g., mobile device, tablet,wearable devices, etc.) indicated by the user. The devices may have asecure element or may be cloud-based. Embodiments of the invention makepossible in-app provisioning of the card onto the user's device.

In some embodiments, the user may not be restricted to utilizing thetokens for recurring payments. For example, once a token is provisionedto a merchant or device, the token can be utilized for any transactionof any type (e.g., recurring, one-time, on-demand, etc.). Paymentmethods for the transactions may include eCommerce (electroniccommerce), mCommerce (mobile commerce), In-app (purchases from within anapplication), NFC (near field communication), MST (Magnetic SecureTransmission™).

Further, embodiments of the invention are not limited to instantissuance and newly issued cards. Embodiments of the invention alsoenable provisioning of a user's existing cards to resource providingentities and devices. For example, the user may log in to their mobileor online banking account and push a token tied to one of their existingcards to resource providing entities participating in a tokenizationprogram or to their other devices.

Further, embodiments of the invention are not limited to provisioningtokens to already existing accounts or profiles associated with theresource providing entities. Embodiments of the invention also enablethe user to request the addition of tokens associated with a new orexisting card to a new account or profile associated with a resourceproviding entity, in addition to an existing account or profileassociated with a resource providing entity. In some cases, the new orexisting accounts or profiles may be those associated with the user or asecondary user (e.g., family member, employee, etc.). The new account orprofile can be created upon the user's request to provision tokens tothe resource providing entity.

Before discussing specific embodiments and examples, some descriptionsof terms used herein are provided below.

An “authorization request message” may be an electronic message that issent to a payment processing network and/or an issuer of a payment cardto request authorization for a transaction. An authorization requestmessage according to some embodiments may comply with (InternationalOrganization of Standardization) ISO 8583, which is a standard forsystems that exchange electronic transaction information associated witha payment made by a consumer using a payment device or payment account.The authorization request message may include an issuer accountidentifier that may be associated with a payment device or paymentaccount. An authorization request message may also comprise additionaldata elements corresponding to “identification information” including,by way of example only: a service code, a CVV (card verification value),a dCVV (dynamic card verification value), an expiration date, etc. Anauthorization request message may also comprise “transactioninformation,” such as any information associated with a currenttransaction, such as the transaction amount, merchant identifier,merchant location, etc., as well as any other information that may beutilized in determining whether to identify and/or authorize atransaction.

An “authorization response message” may be an electronic message replyto an authorization request message generated by an issuing financialinstitution or a payment processing network. The authorization responsemessage may include, by way of example only, one or more of thefollowing status indicators: Approval—transaction was approved;Decline—transaction was not approved; or Call Center—response pendingmore information, merchant must call the toll-free authorization phonenumber. The authorization response message may also include anauthorization code, which may be a code that a credit card issuing bankreturns in response to an authorization request message in an electronicmessage (either directly or through the payment processing network) tothe merchant's access device (e.g. POS equipment) that indicatesapproval of the transaction. The code may serve as proof ofauthorization. As noted above, in some embodiments, a payment processingnetwork may generate or forward the authorization response message tothe merchant.

A “token” may include a substitute identifier for some information. Forexample, a payment token may include an identifier for a payment accountthat is a substitute for an account identifier, such as a primaryaccount number (PAN). For instance, a token may include a series ofalphanumeric characters that may be used as a substitute for an originalaccount identifier. For example, a token “4900 0000 0000 0001” may beused in place of a PAN “4147 0900 0000 1234.” In some embodiments, atoken may be “format preserving” and may have a numeric format thatconforms to the account identifiers used in existing payment processingnetworks (e.g., ISO 8583 financial transaction message format). In someembodiments, a token may be used in place of a PAN to initiate,authorize, settle or resolve a payment transaction. The token may alsobe used to represent the original credential in other systems where theoriginal credential would typically be provided. In some embodiments, atoken value may be generated such that the recovery of the original PANor other account identifier from the token value may not becomputationally derived.

A “resource providing entity” may be an entity that may make resourcesavailable to a user. Examples of resource providing entities includemerchants, vendors, suppliers, owners, traders, wallet providers,service providers, and the like. In some embodiments, such entities maybe a single individual, small groups of individuals, or larger groups ofindividuals (e.g., companies). Resource providing entities may beassociated with one or more physical locations (e.g., supermarkets,malls, stores, etc.) and online platforms (e.g., e-commerce websites,online companies, etc.). In some embodiments, resource providingentities may make available physical items (e.g., goods, products, etc.)to the user. In other embodiments, resource providing entities may makeavailable digital resources (e.g., electronic documents, electronicfiles, etc.) to the user. In other embodiments, resource providingentities may manage access to certain resources by the user. In someembodiments, the resources may be services (e.g., digital walletservices). A resource providing entity may also be known as a resourceprovider or the like.

A “participating resource providing entity” may be a resource providingentity that is partaking in a program. In some cases, the participatingresource providing entity may be a resource providing entity that isenrolled in a tokenization program. For example, the participatingresource providing entity may have an account with a token serviceprovider (e.g., processor server computer) and may be able to processtransactions conducted utilizing tokenized account information (e.g.,tokens).

An “authorization computer” can include any system involved inauthorization of a transaction. The authorization computer may beoperated by an authorizing entity. The authorization computer maydetermine whether a transaction can be authorized and may generate anauthorization response message including an authorization status (alsomay be known as an authorization decision). In some embodiments, anauthorization computer may be a payment account issuer computer. In somecases, the authorization computer may store contact information of oneor more users. In other embodiments, the authorization computer mayauthorize non-financial transactions involving a user. For example, theauthorization computer may make an authorization decision regardingwhether the user can access a certain resource.

“Account information” may refer to any information associated with auser's account (e.g., a payment account and/or payment device associatedwith the account). Such information may be directly related to theaccount or may be derived from information related to the account.Examples of account information may include a PAN (Primary AccountNumber or “account number”), user name, expiration date, CVV (CardVerification Value), dCVV (Dynamic Card Verification Value), CVV2 (CardVerification Value 2), CVC3 card verification values, etc. CVV2 isgenerally understood to be a static verification value associated with apayment device. CVV2 values are generally visible to a user (e.g., aconsumer), whereas CVV and dCVV values are typically embedded in memoryor authorization request messages and are not readily known to the user(although they are known to the issuer and payment processors). In somecases, account information may also be known as card accountinformation.

“Contact information” may refer to any information that can be utilizedto communicate with a user. For example, contact information may includean email address, a phone number, IP address, or other information. Insome embodiments, contact information may serve as an alias identifierfor a user.

“Transaction data” (which may also be known as transaction information)may refer to any data or information surrounding or related to atransaction. For example, transaction data may include transactiondetails and any data associated with the transaction that may beutilized by entities involved in the transaction process. For instance,the transaction data may include information useful for processingand/or verifying the transaction. Transaction data may also include anydata or information surrounding or related to any participants partakingin or associated with the transaction. Example transaction data mayinclude a transaction amount, transaction location, resources received(e.g., products, documents, etc.), information about the resourcesreceived (e.g., size, amount, type, etc.), resource providing entitydata (e.g., merchant data, document owner data, etc.), user data, dateand time of a transaction, payment method, and other relevantinformation.

A “card on file” may be alternatively referred to as an “account onfile.” An account on file may refer to an account identifier (e.g., anaccount number) that is on file with a resource providing entity, suchas a merchant, digital wallet, or other entity. In such situations, theaccount identifier may be used by a user to conduct purchases with theresource providing entity. The user does not need to specificallyprovide his or her account number to the resource providing entity whenconducting a transaction, since the resource providing entity alreadyhas it. In some embodiments, account on file purchases may vary infrequency and/or amount and may represent an agreement between acardholder and a merchant to purchase goods or services provided over aperiod of time or on demand.

A “server computer” can be a powerful computer or a cluster ofcomputers. For example, the server computer can be a large mainframe, aminicomputer cluster, or a group of servers functioning as a unit. Inone example, the server computer may be a database server coupled to aWeb server.

FIG. 1 shows an exemplary flow diagram 100 of a method according toembodiments of the present invention. FIG. 1 includes a user device 10that can communicate with an access device 12. FIG. 1 also includes auser device 14. User device 10 and user device 14 may have similarcharacteristics to those described for user device 103 in FIG. 4.

Access device 12 may be any suitable device that provides access to aremote system. Access device 12 may be in any suitable form. Someexamples of access devices include POS or point of sale devices (e.g.,POS terminals), cellular phones, PDAs, personal computers (PCs), tabletPCs, hand-held specialized readers, set-top boxes, electronic cashregisters (ECRs), automated teller machines (ATMs), virtual cashregisters (VCRs), kiosks, security systems, access systems, and thelike. Access device 12 may use any suitable contact or contactless modeof operation to send or receive data from, or associated with, userdevice 10.

In some embodiments, where access device 12 may comprise a POS terminal,any suitable POS terminal may be used and can include a reader, aprocessor, and a computer-readable medium. A reader may include anysuitable contact or contactless mode of operation. For example,exemplary card readers can include radio frequency (RF) antennas,optical scanners, bar code readers, or magnetic stripe readers tointeract with a payment device and/or mobile device. In someembodiments, a cellular phone, tablet, or other dedicated wirelessdevice used as a POS terminal may be referred to as a mobile point ofsale or an “mPOS” terminal.

At step S1, the user may apply for a new account. In some embodiments,the user may see an advertisement for creating the new account, wherethe advertisement may lead to a website from which the user can send arequest to apply for the new account. The website may be hosted by anauthorization computer associated with an authorizing entity (e.g.,issuer) that may issue the new account.

The advertisement may be in various forms. In some cases, theadvertisement may be in the form of a physical poster, which may includea scannable code (e.g., QR code) or printed link. The user may scan thescannable code, which may open a browser on user device 10. In othercases, the user may type in the printed link to open the website. Inother cases, the advertisement may be received by email or text message,and may include a link that the user may activate to be routed to thewebsite. In yet other embodiments, the advertisement may be an onlineadvertisement that may appear when the user is browsing the web. Theadvertisement may be clicked to route the user to the website.

After being routed the website, the user may be prompted to inputinformation to apply for the new account. In some cases, the informationmay include a name, address, and contact information (e.g., emailaddress, a phone number, etc.). In some cases, upon entering theinformation, the user may confirm the information by activating asoftware button (e.g., “Apply Now” button). This may trigger theinformation input by the user to be sent to the authorization computer,which may conduct an approval process to determine whether the newaccount can be created for the user. If generation of the account isapproved, the authorization computer may generate the new accountassociated with the user. In some cases, generating the new account maycomprise generating an account identifier associated with the newaccount.

At step S2, the user may be prompted with a plurality of participatingresource providing entities from which the user can make a selection.The participating resource providing entities may be entitiesparticipating in a tokenization program. By selecting a resourceproviding entity, the user may indicate that they want to provision atoken associated with the new account to the resource providing entity.In some cases, the participating resource providing entities may includevarious merchants, digital wallet providers, and service providers withwhich the user may or may not have an existing account or profile.

The user may be prompted with any suitable interface that enablesselection of one or more participating resource providing entities. Insome cases, the user interface may comprise selectable tiles labeledwith identifiers (e.g., names) associated with a corresponding resourceproviding entity as shown in FIG. 1. In other cases, the user interfacemay comprise selectable checkboxes as shown by user interface 200 inFIG. 2. Other exemplary user interfaces may include other selectableuser interface elements, such as radio buttons, dropdown lists, listboxes, buttons, toggle, sliders, and icons.

In some embodiments, the participating resource providing entities maybe presented in the user interface in a certain manner. For example, insome cases, the participating resource providing entities may bepre-selected when presented in the interface. In some cases, thereparticipating resource providing entity may also be displayed at the topof the list of participating resource providing entities presented inthe user interface. This may allow the user to easily confirm whether toadd the new account to these pre-selected participating resourceproviding entities. However, the user may de-select any of thepre-selected participating resource providing entities to indicate thattokens associated with the new account should not be provisioned to thatparticular participating resource providing entity. The user may alsoselect any additional participating resource providing entities to whichtokens associated with the new account should be provisioned.

In some cases, upon making a selection of participating resourceprovider entities, the user may confirm the selection by activating asoftware button (e.g., “Confirm” button). This may trigger the selectionto be sent to the authorization computer or to a processor servercomputer (e.g., token service provider). A token associated with the newaccount may be provisioned to each of the selected participatingresource providing entities.

In an exemplary case, one of the selected participating resourceproviding entities may be a digital wallet provider. If the user alreadyhad an account associated with the selected digital wallet provider, atoken may be provisioned to the existing account. If the user did notalready have an account associated with the selected digital walletprovider, an account may be generated after which a token may beprovisioned to the account associated with the digital wallet provider.

In an exemplary case, one of the selected participating resourceproviding entities may be a merchant. If the user already had an accountassociated with the selected merchant (e.g., account on file), a tokenmay be provisioned to the existing account. If the user did not alreadyhave an account associated with the selected merchant, an account may begenerated after which a token may be provisioned to the accountassociated with the merchant.

At step S3, the user may conduct a transaction utilizing a tokenprovisioned to a selected participating resource providing entity. Theselected participating resource providing entity may be a digital walletprovider, as described in the exemplary case above. The user may utilizeuser device 10 to run an application hosted by the digital walletprovider. In some embodiments, the application may be a digital walletapplication that enables contactless transactions. In some cases, theuser may indicate to the application to utilize the provisioned tokenfor the transaction. In other cases, information related to the tokenmay be pre-filled by the application. User device 10 may thencommunicate account information including the token to access device 12to conduct the transaction. As a result, the new account can be utilizedto conduct a transaction with the digital wallet application instantlyafter issuance.

At step S4, the user may conduct another transaction utilizing a tokenprovisioned to another selected participating resource providing entity.The selected participating resource providing entity may be a merchant,as described in the exemplary case above. In some embodiments, the usermay utilize user device 14 to conduct the transaction utilizing theprovisioned token. In some embodiments, user device 14 may run a websiteor application hosted by the merchant. In some cases, the user mayindicate to the application or website to utilize the provisioned tokenfor the transaction. In other cases, information related to the tokenmay be pre-filled by the application or website. The user may thenconduct the transaction with the merchant using the provisioned token.As a result, the new account can be utilized to conduct a transactionwith the merchant instantly after issuance.

While exemplary cases in which the user operates user device 10 and userdevice 14 are described above, embodiments are not so limited. Forexample, the tokens may be provisioned for use by another secondary user(e.g., family member, employee, etc.). Based upon the selection ofparticipating resource providing entities by the user, the secondaryuser may be able to conduct transactions utilizing tokens associatedwith the user's account with the selected participating resourceproviding entities.

Further, while exemplary cases in which the provisioned token areassociated with a newly issued account, embodiments are not so limited.For example, the provisioned token may be for an existing accountassociated with the user. In this case, the user may open an applicationassociated with an authorization entity on user device 10, where theapplication may host the existing account. The user may indicate thatthey want to provision tokens associated with the existing account to aplurality of selected participating resource providing entities. For anyof the selected participating resource providing entities with which noaccount or profile exists, an account or profile may be generated beforea token is added to the generated account or profile. As a result, theuser may control the provisioned tokens from the application associatedwith the authorization entity, while each of the selected resourceproviding entities may store the token for future use.

Embodiments of the invention may enable provisioning of tokens forvarious use cases, such as those shown in Table 1 below.

TABLE 1 Resource providing Account from entity account to which tokenswhich tokens are are issued provisioned Use case description New NewAccount/ User signs up for new card and Account Profile wants to add thenew card to a new account/profile associated with a resource providingentity. New Existing User signs up for new card and AccountAccount/Profile wants to add the new card to an existing account/profileassociated with a resource providing entity. New Secondary User Usersigns up for new card and Account Account/Profile wants to add the newcard to a secondary user's account/ profile (new or existing) associatedwith a resource providing entity. Existing New Account/ User wants toadd an existing Account Profile card to a new account/profile associatedwith a resource providing entity. Existing Existing User wants to add anexisting Account Account/Profile card to an existing account/ profileassociated with a resource providing entity. Existing Secondary UserUser wants to add an existing Account Account/Profile card to asecondary user's account/profile (new or existing) associated with aresource providing entity.

In some embodiments, the user may manage the provisioned tokens throughan application (e.g., hosted by authorization entity) or a third partytoken portal. An exemplary user interface 300 is shown in FIG. 3.Activation of any of the user interface elements (e.g., buttons) of userinterface 300 may open another user interface that enables the user toview data and configure setting associated with provisioned tokens. Forexample, activating the “History” button may enable the user to reviewhistorical information (e.g., historical transactions) for any of theprovisioned tokens. Activating the “Suspend” button may enable the userto request to suspend use of any of the provisioned tokens. In anexemplary case, the user may indicate to suspend use (e.g., temporarily)of a provisioned token by a particular secondary user or a certaindevice. Activating “Delete” button may enable the user to requestdeletion of any of the provisioned tokens from the correspondingresource providing entity systems. Activating the “Controls” button mayenable the user to configure and execute controls (e.g., spend controls,time limit controls, etc.) for the provisioned tokens. For example, theuser may configure a provisioned token to be authorized for use withtransactions below a certain transaction amount. Activating the “Alerts”button may enable the user to configure alert setting indicating whenthe user should receive an alert regarding the provisioned tokens. In anexemplary case, the user may configure alert setting so that an alert issent when a provisioned token is utilized over a day for transactionsthat sum to greater than a certain transaction amount.

FIG. 4 illustrates an exemplary system 400 with at least some of thecomponents for implementing embodiments of the invention. FIG. 4includes a user 101, a user device 103 operating a service providerapplication 113, a resource provider computer 106, a transport computer108, a processor server computer 110 in communication with a token vault116, an authorization computer 112, and a service provider computer 114.Any of the computing devices (e.g., user device 103, resource providercomputer 106, transport computer 108, processor server computer 110,service provider computer 114, and authorization computer 112) in FIG. 1may be in communication by any suitable communications network.

The communications network may comprise a plurality of networks forsecure communication of data and information between entities. In someembodiments, the communications network may follow a suitablecommunication protocol to generate one or more secure communicationchannels between user device 103 and processor server computer 110. Anysuitable communications protocol may be used for generating acommunications channel. A communication channel may in some instancecomprise a “secure communication channel,” which may be established inany known manner, including the use of mutual authentication and asession key and establishment of an SSL session. However, any method ofcreating a secure channel may be used. By establishing a secure channel,sensitive information may be securely transmitted to facilitate atransaction.

A user 101 (which may also be known as a consumer) may be a cardholderoperating user device 103. User 101 may select one or more resourceproviding entities (e.g., merchants, digital wallet services providers,service providers etc.) to which to provision tokens associated with anaccount. In some embodiments, the account may be an existing accountassociated with user 101. In other embodiments, user 101 may requestgeneration of a new account (e.g., new card account) from authorizationcomputer 112. In some embodiments, user 101 may utilize the provisionedtokens associated with the account with service provider application 113or other platforms related to the selected one or more resourceproviding entities to conduct a transaction using user device 103.

User device 103 may be any suitable device to conduct a transaction.User device 103 may include a memory that may store service providerapplication 113 and may be utilized to conduct transactions usingservice provider application 113. User device 103 may communicate over acommunications network with one or more entities, including serviceprovider computer 114 and processor server computer 110. User device 103may be utilized in a card-not-present transaction, such as through awebsite hosted by a resource providing entity. In some embodiments, userdevice 103 may also be capable of communicating by contact or wirelesslywith an access device at a payment terminal. In some embodiments,payment methods for the transactions may include eCommerce (electroniccommerce), mCommerce (mobile commerce), In-app (purchases from within anapplication), NFC (near field communication), MST (Magnetic SecureTransmission™).

Some non-limiting examples of user device 103 may include mobile devices(e.g., cellular phones, keychain devices, personal digital assistants(PDAs), pagers, notebooks, laptops, notepads, smart watches, fitnessbands, jewelry, etc.), automobiles with remote communicationcapabilities, personal computers, payment cards (e.g., smart cards,magnetic stripe cards, etc.), and the like. In some embodiments, userdevice 103 may be configured to communicate with one or more cellularnetworks.

Service provider application 113 may be accessible by user device 103.Service provider application 113 may be operated by service providercomputer 114. In some embodiments, service provider application 113 maystore a digital wallet and may include card account informationassociated with user 101. In some cases, the digital wallet may be amobile wallet. Some exemplary service provider applications include awallet application, a digital wallet application, a wallet providerapplication, a mobile wallet application, or the like.

Service provider computer 114 may issue a service provider account for auser. In some embodiments, service provider computer 114 may beassociated with a service provider. In some cases, the service providermay be an application provider, which may be an entity that provides anapplication to a mobile device for use by a user. In some embodiments,the service provider may be a wallet provider computer and can provide amobile wallet or payment application (e.g., wallet application) to theuser device 103. Service provider computer 114 may operate a servercomputer that may send and receive messages to and from service providerapplication 113 on user device 103. The service provider account issuedby service provider computer 114 may also be accessed by a website. Insome embodiments, the service provider computer 114 may maintain one ormore digital wallets for each user, and each digital wallet may beassociated with payment data for one or more payment accounts. Anexample of a digital wallet may be Visa Checkout™. In some cases, theservice provider may be known as a resource provider and serviceprovider computer 114 may be known as a resource provider computer.

Resource provider computer 106 may be configured to receive and processtransaction data. In some embodiments, the transaction data may bereceived from user device 103 or an access device in communication withuser device 103. Resource provider computer 106 may engage intransactions, sell goods or services, or provide access to goods orservices to the consumer. Resource provider computer 106 may accepttransaction data in multiple forms and may use multiple tools to conductdifferent types of transactions. For example, resource provider computer106 may sell goods and/or services via a website or application, and mayaccept payments over the Internet. Resource provider computer 106 mayalso be associated with a physical store that utilizes an access devicethat can receive transaction data from user device 103 for in-persontransactions.

Transport computer 108 is typically a system for an entity (e.g., abank) that has a business relationship with a particular merchant orother entity. Transport computer 108 may route an authorization requestfor a transaction to authorization computer 112 via processor servercomputer 110. In some cases, transport computer 108 may be known as anacquirer computer.

Processor server computer 110 may include data processing subsystems,networks, and operations used to support and deliver authorizationservices, and clearing and settlement services. An example of processorserver computer 110 includes VisaNet®, operated by Visa®. Processorserver computer 110 may include wired or wireless network, including theInternet. In some embodiments, processor server computer 110 may be atoken service provider and may be in communication with token vault 116,which may store tokens associated with accounts of user 101. In somecases, processor server computer 110 may also be known as a paymentprocessing server computer.

Token vault 116 may comprise any information related to tokens. Forexample, token vault 116 may store tokens associated with serviceprovider application 113 and a mapping of the tokens to their associatedaccounts. Token vault 116 may comprise any sensitive information (e.g.,account number) associated with the tokens. In some embodiments,processor server computer 110 may communicate with token vault 116 tode-tokenize a token. In some cases, token vault 116 may reside atprocessor server computer 110.

Authorization computer 112 may be a computer involved in authorizationprocesses. In some embodiments, authorization computer 112 may be run byan entity that can issue accounts. When a transaction involves anaccount issued by authorization computer 112, authorization computer 112may verify the account and respond with an authorization responsemessage to transport computer 108 that may be forwarded to an accessdevice, if applicable. Some systems may perform functions of bothauthorization computer 112 and transport computer 108.

Upon receiving a request from user 101 by user device 103 for a newaccount, authorization computer 112 may approve user 101 and prompt user101 to select resource providing entities with which to utilize the newaccount. In some embodiments, authorization computer 112 may communicatewith processor server computer 110 to request tokenization of the newlyapproved account. In some embodiments, authorization computer 112 may bean issuer computer associated with an authorizing entity (e.g., issuerbank) that issues a payment (credit/debit) card, account numbers orpayment tokens utilized for the transactions.

At a later time (e.g., at the end of the day), a clearing and settlementprocess can occur between transport computer 108, processor servercomputer 110, and authorization computer 112.

Any of the computing devices (e.g., user device 103, resource providercomputer 106, transport computer 108, processor server computer 110,service provider computer 114, and authorization computer 112) mayinclude a processor and a computer readable medium comprising code,executable by the processor for performing the functionality describedherein.

Embodiments of the invention enable provisioning of tokens to resourceproviding entities. There are several configurations of systems andcomputers, such as those described in FIG. 4, that can be utilized toaccomplish the provisioning of tokens. One exemplary case may comprise aone-to-many implementation and another exemplary case may comprise aone-to-one implementation, which are described in more detail below.

Embodiments of the invention may enable a one-to-many implementation inwhich an authorization computer may integrate with a plurality ofresource providing entities through a single connection with a tokenprovider, which may be a processor server computer. While not explicitlyshown in FIG. 4, processor server computer 110 may be in communicationwith a plurality of resource providing entities participating in atokenization program. Processor server computer 110 may provision tokensto the plurality of resource providing entities upon request byauthorization computer 112. Descriptions with respect to FIG. 5 and FIG.6 below describe an exemplary one-to-many implementation in furtherdetail.

FIG. 5 shows a block diagram 500 of an exemplary system enabling aone-to-many implementation according to embodiments of the presentinvention. FIG. 5 includes a plurality of authorization computers 512 incommunication with a processor server computer 510. In some embodiments,processor server computer 510 may be a token provider or token serviceprovider. Each of authorization computers 512 may have similarcharacteristics to those described with respect to authorizationcomputer 112 in FIG. 4. Processor server computer 510 may have similarcharacteristics to those described with respect to processor servercomputer 110 of FIG. 4.

Processor server computer 510 may be capable of communicating with aplurality of resource providing entities. In some cases, processorserver computer 510 may provision tokens to any of the plurality ofresource providing entities upon request by any of authorizationcomputers 512. The resource providing entities may include thoseassociated with service provider computers 501, issuer digital walletprovider computers 502, third party digital wallet provider computers503, merchant computers 504, and networked devices 505. Service providercomputer 501 may be associated with any service providers that may storeand utilize tokens for transactions. In some embodiments, serviceprovider computers 501 may be provide services (e.g., Visa Checkout™)associated with processor server computer 510. Issuer digital walletprovider computers 502 may enable digital wallets for accounts issued byan authorization computer. Third party digital wallet provider computers503 may be associated with third parties that provide digital walletsthat may store a plurality of accounts. Digital wallets provided byissuer digital wallet provider computers 502 and third party digitalwallet provider computers 503 may utilize tokens for transactionsconducted with the digital wallets. Merchant computers 504 may beassociated with a merchant, which may enable transactions to beconducted utilizing tokens. In some cases, merchant computers 504 maystore accounts on file with information related to the tokens. Networkeddevices 505 may be any suitable devices that can communicate with othercomputing devices and may store data. In some embodiments, networkeddevices 505 may be known as IoT devices (Internet of Things devices),which may include wearable devices that can be utilized to conducttransactions with tokens.

In a one-to-many implementation, an exemplary process as shown in flowdiagram 600 of FIG. 6 may be performed. FIG. 6 may include user device601 in communication with an authorization computer 612, a processorserver computer 610, and a resource provider computer 615. User device601 may have similar characteristics to those described with respect touser device 103 in FIG. 4. Authorization computer 612 may have similarcharacteristics to those described with respect to authorizationcomputer 112 of FIG. 4, as well as authorization computers 512 of FIG.5. Processor server computer 610 may have similar characteristics tothose described with respect to processor server computer 110 of FIG. 4and processor server computer 510 of FIG. 5. Resource provider computer615 may have similar characteristics to those described with respect toresource provider computer 106 of FIG. 4 and any of resource providercomputers 501-505 of FIG. 5.

At step S61, user device 601 operated by a user may communicate withauthorization computer 612. In some embodiments, user device 601 may runan application hosted by authorization computer 612. In otherembodiments, user device 601 may run a browser for a website hosted byauthorization computer 612. From within the application or browser, theuser may send a request to provision tokens associated with theiraccount (e.g., new or existing) to a plurality of selected resourceproviding entities. The resource providing entities may also be known astoken requestors.

At step S62, authorization computer 612 may communicate with processorserver computer 610 to request provisioning of the tokens. Processorserver computer 610 may be a service provider that provides tokenizationservices. Processor server computer 610 may generate tokens for each ofthe plurality of resource providing entities.

At step S63, processor server computer 610 may communicate with resourceprovider computer 615. Resource provider computer 615 may be associatedwith a resource providing entity from the plurality of selected resourceproviding entities. In some cases, processor server computer 610 maysend a token generated for the resource providing entity associated withresource provider computer 615 to resource provider computer 615. Priorto provisioning the token, an authentication process may be conductedbetween the user and resource provider computer 615. Variousauthentication methods may be utilized in the one-to-manyimplementation.

One type of authentication method may be straight through provisioning.In this case, existing integrations (e.g., Security Assertion MarkupLanguage) between authorization computer 612 and processor servercomputer 610 may be leveraged. Processor server computer 610 may provideservices that enable account creation and loading authenticationinformation for resource providing entities. In an exemplary case, aservice provided by processor server computer 610 may be Visa Checkout™.The user may access their Visa Checkout™ account through the applicationor website hosted by authorization computer 612 for authentication whenrequesting provisioning of the tokens.

Another exemplary authentication method for the one-to manyimplementation may utilize a pop-up display or the like. For example,when a user utilizes an application or website hosted by authorizationcomputer 612 to request provisioning of tokens, a lightbox display mayappear. The lightbox display may be pre-populated with some informationrelated to the user. In some cases, the lightbox display may prompt theuser to enter or create a password for an account or profile associatedwith resource provider computer 615 to which a token is to beprovisioned.

At steps S64 and S65, resource provider computer 615 may sendinformation confirming that the token was provisioned. In someembodiments, the information may be sent to authorization computer 612via processor server computer 610. While FIG. 6 shows a single resourceprovider computer 615, it is understood that the authentication processand token provisioning process may be performed for each of theplurality of resource providing entities selected by the user.

The one-to-many implementation as described above also enablesauthorization computers to select preferences related to authenticationthrough a single platform, which is convenient. This configuration ofpreference may occur at any time. For example, authorization computer612 may login to their account hosted by a processor server computer610. Authorization computer 612 may select channels (e.g., application,browser, etc.) for which to enable push provisioning of tokens.Authorization computer 612 may further select authentication methodsthat are supported (e.g., Visa Checkout™, lightbox display, etc.).Authorization computer 612 may view a list of all resource providingentities (e.g., token requestors) that are compatible for pushprovisioning of tokens based on the selected channels and authenticationmethods. In some embodiments, authorization computer 612 may also viewother information, such as reasons as to why some resource providingentities cannot be supported for push provisioning (e.g., incompatiblechannel or authentication method). The one-to-many implementation mayenable authorization computers to “opt-in” for tokenization programseasily without having to interface with multiple resource providingentities.

In some embodiments, processor server computer 610 may determine andcompare authentication methods and authentication channels supported byauthorization computer 612 and those supported by a resource providingentity to determine whether the resource providing entity is to beprovided to the user for selection. If the compared authenticationmethods and authentication channels match for an authorization computerand a resource providing entity match, processor server computer 610 maynotify authorization computer 612 of the resource providing entity.Subsequently, authorization computer 612 may then prompt the user with alist of participating resource providing entities including the resourceproviding entity. In some embodiments, this comparison process may beconducted for each of the participating resource providing entities inthe list of participating resource providing entities.

Embodiments of the invention may also enable another type ofimplementation, which may be known as a one-to-one implementation. Aone-to-one implementation may enable an authorization computer tointegrate directly with resource providing entities on an individualbasis. For example, an authorization computer may enable tokenprovisioning to each resource providing entity separately based on astandard (e.g., associated with a processor server computer) orproprietary APIs (e.g., push provisioning API). FIG. 7 and FIG. 8 belowdescribe an exemplary one-to-one implementation in further detail.

FIG. 7 shows a block diagram 700 of an exemplary system enabling aone-to-one implementation according to embodiments of the presentinvention. FIG. 7 includes an authorization computer 710, anauthorization computer 711, and an authorization computer 712. Each ofauthorization computers 710, 711, and 712 may have similarcharacteristics to those described with respect to authorizationcomputer 112 in FIG. 4. FIG. 7 also includes a resource providercomputer 720, a resource provider computer 721, and a resource providercomputer 722. Each of resource provider computers 720, 721, and 722 mayhave similar characteristics to those described with respect to resourceprovider computer 106 of FIG. 4. Only three authorization computer andthree resource provider computers are shown in FIG. 7 for simplicity.However, embodiments are not so limited and any suitable number ofauthorization computers and resource provider computers may exists in aone-to-one implementation.

In a one-to-one implementation as shown in FIG. 7, each authorizationcomputer may integrate directly with each resource provider computer(e.g., token requestor). Thus, an intermediary entity, such as aprocessor server computer, that handles all tokenization may be notpresent. This may provide the ability for integration with each resourceprovider computer to be performed based on either a standard (e.g.,associated with a processor server computer) or proprietary pushprovisioning APIs specific to the resource provider computer.

In a one-to-one implementation, an exemplary process as shown in flowdiagram 800 of FIG. 8 may be performed. FIG. 8 may include user device801 in communication with an authorization computer 812, a resourceprovider computer 815, and a processor server computer 810. User device801 may have similar characteristics to those described with respect touser device 103 in FIG. 4. Authorization computer 812 may have similarcharacteristics to those described with respect to authorizationcomputer 112 of FIG. 4, as well as any of authorization computers710-712 of FIG. 7. Processor server computer 810 may have similarcharacteristics to those described with respect to processor servercomputer 110 of FIG. 4. Resource provider computer 815 may have similarcharacteristics to those described with respect to resource providercomputer 106 of FIG. 4 and any of resource provider computers 720-722 ofFIG. 7.

At step S81, user device 801 operated by a user may communicate withauthorization computer 812. In some embodiments, user device 801 may runan application hosted by authorization computer 812. In otherembodiments, user device 801 may run a browser for a website hosted byauthorization computer 812. From within the application or browser, theuser may send a request to provision tokens associated with theiraccount (e.g., new or existing) to a plurality of selected resourceproviding entities. The resource providing entities may also be known astoken requestors.

At step S82, authorization computer 812 may communicate with resourceprovider computer 815 to request provisioning of a token to resourceprovider computer 815. Resource provider computer 815 may be associatedwith a resource providing entity from the plurality of resourceproviding entities selected by the user. In some embodiments, anauthentication process may be performed between the user and resourceprovider computer 815.

One type of authentication method may comprise redirecting the user to achannel associated with the resource providing entity. For example, theuser may be redirected from the application or browser hosted byauthorization computer 812 to an application or website hosted byresource provider computer 815. In some embodiments, a page may bedisplayed prompting the user for information to complete accountcreation or the authentication process. For example, the user may createor enter a password to be utilized with their account or profile hostedby resource provider computer 815.

Another type of authentication method may comprise sending a message toenable a secondary user to login or create an account with the resourceproviding entity. For example, in some cases, the user may want toprovision a token to a secondary user's account (e.g., family member'saccount, employee's account, etc.). In some embodiments, the user mayenter an channel identifier (e.g., email address, phone number, etc.)associated with the secondary user, and authorization computer 812 maysend a message to the secondary user through a channel (e.g., email,text message, etc.) associated with the channel identifier. The messagemay include a link that may direct the secondary user to an applicationor website hosted by resource provider computer 815, which may promptthe secondary user to input information to login or create an account.For example, the secondary user may create or enter a password to beutilized with their account or profile hosted by resource providercomputer 815.

At step S83, resource provider computer 815 may request a token fromprocessor server computer 810. In some cases, resource provider computer815 may confirm to processor server computer 810 that the user orsecondary user was authenticated based on information provided by theuser before the token can be generated.

At step S84, processor server computer 810 may generate and provision atoken to resource provider computer 815. Processor server computer 810may generate a token meant for use with resource provider computer 815and send it to resource provider computer 815.

At step S85, resource provider computer 815 may send informationconfirming that the token was provisioned. In some embodiments, the usermay be redirected back to the application or website hosted byauthorization computer 812. While FIG. 8 shows a single resourceprovider computer 815, it is understood that the authentication processand token provisioning process may be performed for each of theplurality of resource providing entities selected by the user. In theone-to-one implementation, each authentication process performed may bespecific to each resource provider computer.

FIG. 9 through FIG. 12 show flow diagrams for exemplary methods that maybe performed according to embodiments of the invention. However, it isunderstood that additional methods and processes may be included withinthese methods and may be recognized by one of ordinary skill in the art,in light of the description below. Further, in some embodiments of thepresent invention, the described methods may be combined, mixed, andmatched, as one of ordinary skill would recognize.

For example, certain steps described in FIG. 9 and FIG. 12 can bemodified to enable a different use case according to embodiments of theinvention. For example, while FIG. 9 and FIG. 12 are directed toprovisioning account information associated with newly issued cardaccounts, similar processes may be applied for existing card accounts.In this case, the steps for applying for a new card may be omitted.Instead, the flow may start with the user device of the user running anapplication or browser hosted by authorization computer 912, which mayalready store information for an existing account.

A method according to the embodiments of the invention can be describedwith respect to FIG. 9 FIG. 9 shows a flowchart 900 of a method forenabling a user immediate card access upon approval and tokenprovisioning to resource providing entities according to embodiments ofthe invention. FIG. 9 includes a user device 903 operated by a user, aresource provider computer 906 associated with a resource providingentity, processor server computer 910, authorization computer 912associated with an authorizing entity, and service provider computer914. In some embodiments, authorization computer 912 may also be knownas an issuer computer, service provider computer 914 as a digital walletprovider, and resource provider computer 906 as a merchant computer. Insome cases, the user may have an account on file with resource providercomputer 906. Processor server computer 910 may also be a token serviceprovider.

At step 1, resource provider computer 906 may send a request toprocessor server computer 910 to sign up for tokenization. This sign upprocess may be conducted at any time prior to a transaction. Theresource providing entity associated with resource provider computer 906may request processor server computer 910 to participate in tokenizedtransactions, in which a user may utilize a token when making a paymentwith the resource providing entity. Upon receiving the request,processor server computer 910 may store information indicating theresource providing entity as a participating resource providing entity.

At step 2, the user may apply for a new card account using their userdevice 903. In some embodiments, the user may receive a promotion (e.g.,by email, text message, etc.) to create a new card. The promotion mayinclude a link which the user may activate to initiate a request for thenew card. The user may activate the link (e.g., by clicking the link),which may launch an application (e.g., banking application) on userdevice 903. In some embodiments, the application may be hosted byauthorization computer 912. The application may display a user interfacerequesting the user to enter information to be utilized to create thenew card account with the authorizing entity associated withauthorization computer 912. The user may enter the user information intouser device 903.

At step 3, user device 903 may send a request for the new card accountincluding the information entered by the user to authorization computer912. In some embodiments, the information may include user information,such as name, address, and other contact information associated with theuser.

At step 4, authorization computer 912 may approve the user based on theentered information. If authorization computer 912 approves the user,authorization computer 912 may issue the new card to the user.Authorization computer 912 may generate card account information for thenew card requested by the user. In some embodiments, the card accountinformation may include an account identifier (e.g., account number), anexpiration date, a card verification value (CVV), and other transactioninformation that may be utilized for a transaction.

At step 5, authorization computer 912 may send the card accountinformation for the new card and the user information to processorserver computer 910. The information may be sent in any suitable manner,such as by an electronic message sent over a communications network.Processor server computer 910 may be a token service provider.

At step 6, processor server computer 910 may notify authorizationcomputer 912 about a list of the participating resource providingentities that signed up for tokenization. In this exemplary case,resource provider computer 906 and service provider computer 914 may beassociated with participating resource providing entities. In someembodiments, resource provider computer 906 may also be known as amerchant computer and service provider computer 914 may also be known asa digital wallet provider computer. Additionally, in some embodiments,processor server computer 910 may notify authorization computer 912about a list of entities with preexisting tokens and thus already havean account on file associated with the user. This may enable instantassociation with preexisting tokens associated with the user.

At step 7, authorization computer 912 may prompt the user to make aselection from the participating resource providing entities with whichutilize the new card. For example, authorization computer 912 may promptthe user using a user interface (e.g., including a list, tile options,etc.) displayed on user device 903 including the participating resourceproviding entities that are signed up for tokenization. In someembodiments, authorization computer 912 may also provide pre-selectedresource providing entities that correspond to those resource providingentities with which the user already has an account (e.g., token) onfile. However, the user may deselect any of the pre-selected resourceproviding entities if the user does not desire to utilize their new cardwith any of the pre-selected resource providing entities. Thus, theresource providing entities options provided to the user may be thosewith which the user may or may not already have an account on file.While FIG. 9 shows authorization computer 912 communicating directlywith user device 903, embodiments are not so limited. For example,authorization computer 912 may send communications indirectly to userdevice 903 through another computer (e.g., processor server computer910).

At step 8, the user may select one or more resource providing entitiesfrom the received list. The selection may be indicated by any suitableinteraction with the user interface displayed on the user device of theuser. For example, the user may confirm their selection by clicking onsoftware or hardware buttons (e.g., checkboxes, tiles, etc.), inputtinga voice command, or other suitable methods. In an exemplary case, theuser may select a resource providing entity associated with resourceprovider computer 906 and a resource providing entity associated withservice provider computer 914. While the exemplary case in which theuser selects two resource providing entities is described in flowchart900, in other embodiments, the user may select any suitable number ofresource providing entities. User device 903 may send the selection ofthe one or more resource providing entities to processor server computer910 with a request to issue tokens associated with the account of theuser to the selected one or more resource providing entities

In some embodiments, processor server computer 910 may verifycommunications sent from user device 903 in step 8. Processor servercomputer 910 may conduct a verification process based on informationrelated to the user operating user device 903 or user device 903. Forexample, user device 903 may send an identifier (e.g., transactionidentifier) along with the selection of one or more resource providingentities in step 8. In some cases, the identifier may be generated byuser device 903 or authorization computer 912 hosting the application onuser device 903. In some embodiments, the identifier may be generatedbased on any combination of a device identifier, timestamp, userinformation, IP address, or other information. Processor server computer910 may check whether the identifier received from user device 903 instep 8 matches an identifier received previously from user device 903(e.g., at step 3) or authorization computer 912 (e.g., at step 5).

At step 9, processor server computer 910 may tokenize the new card.Processor server computer 910 may generate one or more tokens associatedwith the account of the new card that may be utilized for transactionsby the user. Processor server computer 910 may be in communication witha token vault, which may store the one or more tokens, a mapping betweenthe one or more tokens and the account of the new card issued to theuser, and any other information related to the token. During atransaction, processor server computer 910 may receive the one or moretokens and may de-tokenize the tokens based on information in the tokenvault, so that the transaction can be applied to the appropriate accountassociated with the token.

Processor server computer 910 may determine a token for each selectedresource providing entity. Determining a token may comprise generating atoken or identifying a token, if the token has been pre-generated. Forexample, processor server computer 910 may determine a first token to beprovisioned to service provider computer 914 and a second token to beprovisioned to resource provider computer 906. Both the first token andthe second token may be associated with the newly issued card byauthorization computer 912. In the exemplary flowchart 900, the user mayalready be enrolled with service provider computer 914 and may have anaccount on file with resource provider computer 206.

At step 10, processor server computer 910 may send the user informationand the first token to service provider computer 914. Service providercomputer 214 may be associated with a wallet provider selected by theuser and that is supported by the authorizing entity associated withauthorization computer 912. The user information and the first token maybe sent in any suitable manner, such as by an electronic message sentover a communications network.

At step 11, service provider computer 914 may authenticate the user. Insome embodiments, service provider computer 914 may conduct anauthentication process with backend processing without requesting inputfrom the user, such as checking whether the received user informationmatches information associated with the user already stored in itssystems. Further details regarding exemplary authentication processesare described with respect to FIG. 6 above.

At step 12, service provider computer 914 may store the received userinformation and the first token. Service provider computer 914 may storethe first token such that it is associated with the newly issued cardand the user information. Hence, the first token may be provisioneddirectly from the mobile banking application operated by the user toservice provider computer 914.

At step 13, processor server computer 910 may send the user informationand the second token to resource provider computer 906. Resourceprovider computer 906 may be associated with the resource providingentity (e.g., merchant) selected by the user. The user information andthe second token may be sent in any suitable manner, such as by anelectronic message sent over a communications network.

At step 14, resource provider computer 906 may authenticate the user. Insome embodiments, resource provider computer 906 may conduct anauthentication process with backend processing without requesting inputfrom the user, such as checking whether the received user informationmatches information associated with the user already stored in itssystems. Further details regarding exemplary authentication processesare described with respect to FIG. 6 above.

At step 15, resource provider computer 906 may store the received userinformation and the second token. Resource provider computer 906 maystore the second token such that it is associated with the newly issuedcard and the user information. Hence, the second token may beprovisioned directly from the mobile banking application operated by theuser to resource provider computer 906. In some embodiments, the secondtoken may also be stored in association with other accounts on file(e.g., including preexisting tokens) that the user has with resourceprovider computer 906.

In some embodiments, steps 10 through 12 and steps 13 through 15described above may be initiated at the same time or in a differentorder than as shown in flowchart 900. For example, processor servercomputer 910 may send information in step 13, followed by steps 14 and15, to resource provider computer 906 before sending information in step10, flowed by steps 11 and 12, to service provider computer 914, or maysend information to resource provider computer 906 and service providercomputer 914 at the same time.

At step 16, the user may utilize their user device 903 to conducttransactions with their newly provisioned tokens. For example, the usermay access their digital wallet (e.g., by a wallet application)associated with service provider computer 914 and utilize the firsttoken with the digital wallet to make a purchase. Additionally, the usermay access an online website associated with resource provider computer906 and utilize the second token to make another purchase. In subsequentpurchases, the user may utilize the first token and second token. Hence,the tokens can be provisioned when the card is issued, which can enablethe user to immediately access and utilize the tokens for transactions,including with account on file merchants. This is efficient, takesminimal effort by the user, and provides more flexibility for the user.Further, the use of tokenization enables security of the transactionssince sensitive data is masked.

A concrete example of a case in which the steps of flowchart 900 may beperformed is provided below. A user may be operating a user device andmay receive a promotion for a new card by email. The user may click onthe promotion, which can launch their mobile banking application ontheir user device. The user may enter user information to apply for thenew card and send to an issuer hosting the application by pressing an“Apply” button. The issuer may approve the user and the new card may beissued to the user.

Subsequently, the user may be prompted to add their newly issued card(e.g., tokens) to participating resource providing entities. The usermay be presented with a user interface including a list of resourceproviding entity names (e.g., vendors, retailers, digital walletproviders, etc.). The user may select one or more resource providingentities by clicking on the one or more resource providing entitiesindicated on the list. The user may select a digital wallet provider anda merchant, with which the user may already have accounts. A first tokenmay be generated and pushed to the user's digital wallet provideraccount associated with the selected digital wallet provider and asecond token may be generated and pushed to the user's merchant accountassociated with the selected merchant.

The provisioned tokens may then be available for immediate use by theuser. For example, the user may go to a store to purchase a beverage.The user may utilize their digital wallet provider account with theiruser device to pay for the beverage with the account of their newlyissued card. Additionally, the user may shop online with their merchantaccount using the same user device or another device. When the userchecks out to make a purchase, the newly issued card may already beprovisioned such that the user may select it from a list including otheraccounts on file that the user has with the merchant. In other cases,the account information (e.g., token) may be pre-filled on the checkoutpage. Subsequently, the user may then utilize the newly issued card topay for the purchase.

As described above, the user may utilize their new card for transactionsconducted at physical POS (point-of-sale) terminal, as well astransactions conducted remotely. For example, the user may pay for atransaction using their new card by a contactless transaction with anaccess device at a merchant. Additionally, the user may pay for ane-commerce transaction using their new card account. Hence, the userdevice may be any suitable device that may be capable of conducting bothtypes of transactions. Some exemplary payment methods may includeeCommerce (electronic commerce), mCommerce (mobile commerce), In-app(purchases from within an application), NFC (near field communication),and MST (Magnetic Secure Transmission™).

As indicated above with respect to the description related to FIG. 9,embodiments of the invention enable multiple tokens to be provisioned tomultiple resource providing entities. However, it is understood thatFIG. 9 depicts one exemplary case in which two tokens were provisionedto two resource providing entities and is not limiting. For example,embodiments of the invention enable one or more tokens to be provisionedone or more resource providing entities. In some embodiments, more thanone token may be provisioned to a single resource providing entity.

While the description related to FIG. 9 above describes one exemplaryuse of the invention, embodiments are not so limited. For example,embodiments of the invention can also be utilized to provision a tokenrelated to a user's existing cards, rather than just newly issued cards.Further, tokens (e.g., associated with a user's existing cards and newlyissued card) can be provisioned to resource providing entities that maybe participating in a tokenization program, which may not be account onfile merchants. Thus, tokens may be utilized for a variety oftransaction types (e.g., recurring, one-time, on-demand, etc.). In someembodiments, tokens may also be pushed to other devices indicated by theuser (e.g., mobile devices, tablets, wearable devices, etc.).

Embodiments of the invention may provide a number of advantages. Forexample, embodiments of the invention increase efficiency as a user nolonger needs to wait to receive a plastic card in order to utilize a newcard account and can have a new card immediately available, with minimaluser input, on their mobile device once approved by an issuer. Thisforgoes the need for the user to manually set up accounts with multipleresource providing entities, which can be repetitive and cumbersome. Insome cases, embodiments of the invention may enable users to be inclinedto utilize their new card with new resource providing entities includingdigital wallet services and merchants, in addition to resource providingentities with which the user may already have an account on file, sincetokens for the newly issued card can be easily provisioned with minimaluser effort. Additionally, embodiments of the invention enable users toproactively create, view, and manage their tokens, which gives themcontrol, security, flexibility, and the ability to better track theircredentials. Regarding the processor server computer, embodiments of theinvention also provide advantages. For example, leveraging the abilityof token services provided by a processor server computer forgoes theneed to build and manage any token vault by a third party, which may notbe as efficient and secure.

Descriptions corresponding to FIGS. 10-12 below describe exemplarymethods according to embodiments of the invention and are not limiting.For example, while the descriptions describe provisioning tokens to aservice provider computer, which may be a digital wallet provider,embodiments are not so limiting. Similar processes can be performed withany resource provider computer associated with a resource providingentity (e.g., merchant, digital wallet provider, service provider,etc.). For example, the service provider computer in any of the FIGS.10-12 can be replaced with a resource providing computer.

A method according to the embodiments of the invention can be describedwith respect to FIG. 10. FIG. 10 shows a flowchart 1000 of a method forenabling a user immediate card access upon approval according toembodiments of the present invention and includes a user 201, aprocessor server computer 210, an authorization computer 212 associatedwith an authorizing entity, and a service provider computer 214. In someembodiments, processor server computer 210 may also be a token serviceprovider. Any communications sent to and received from user 201 may bethrough a user device, such as user device 103 of FIG. 4, operated byuser 201. In some embodiments, processor server computer 210 may also beknown as a payment processor server computer or payment processingnetwork, authorization computer 21 2 may also be known as an issuercomputer, and service provider computer 214 may also be known as aresource provider computer. In the exemplary case described below,service provider computer 214 may be a wallet provider computer

At step 1, user 201 applies for a new card using their user device. Forexample, user 201 may be shopping online on a merchant website usingtheir user device and may see an advertisement showing that conducting acheckout process with a card issued by the issuer associated withauthorization computer 212 will give user 201 a discount User 201 mayclick on the advertisement, redirecting user 201 to a website associatedwith the authorizing entity and hosted by authorization computer 212.The website may display a user interface requesting user 201 to enterinformation to be utilized to create the new card with the issuer. User201 may enter the information, which may be forwarded to authorizationcomputer 212. In some embodiments, the information may include a userdata (e.g., name, address, contact information, etc.).

At step 2, authorization computer 212 may approve user 201 based on theentered information. If authorization computer 212 approves user 201,authorization computer 212 may issue the new card to user 201.Authorization computer 212 may generate card information for the newcard requested by user 201. In some embodiments, the card informationmay include an account identifier (e.g., account number), other accountinformation (e.g., expiration date, CVV, etc.), and transactioninformation that may be utilized for a transaction. Card information mayalso be known as account information or card account information.

At step 3, authorization computer 212 may send the card information forthe new card to processor server computer 210. In addition to the cardinformation, authorization computer 212 may send cardholder information,cardholder contact information, and any additional future processinginstructions. An example of a future processing instruction may be aninstruction to not validate the consumer address when the consumercreates their account. The card information and additional informationmay be sent in any suitable manner, such as by an electronic messagesent over a communications network. Processor server computer 210 may bea token service provider.

At step 4, processor server computer 210 may activate an accountassociated with the new card and may tokenize the new card. For example,processor server computer 210 may generate a token associated with theaccount of the new card that may be utilized for a transaction by user201. Processor server computer 210 may be in communication with a tokenvault, which may store the token, a mapping between the token and theaccount of the new card issued to user 201, and any other informationrelated to the token. During a transaction, processor server computer210 may receive the token and may de-tokenize the token based oninformation in the token vault so, that the transaction can be appliedto the appropriate account associated with the token.

At step 5, processor server computer 210 may send token information,which may be any information related to the token generated by processorserver computer 210, to authorization computer 212. The tokeninformation may be sent in any suitable manner, such as by an electronicmessage sent over a communications network. In some embodiments,processor server computer 210 may also send authorization computer 212an access link along with the token information. For example, the accesslink may be a link that can redirect user 201 using their user device toa website or application hosted by processor server computer 210.

At step 6, in some embodiments, authorization computer 112 may send aconfirmation that the token information was received from processorserver computer 210. In some embodiments, authorization computer 212 maysend user information received in step 1 to processor server computer210. In other embodiments, the user information may be sent with cardinformation in step 3 or other appropriate step.

At step 7, authorization computer 212 may prompt user 201 to selectwallet providers to utilize with the new card. For example,authorization computer 212 may prompt user 201 by a user interface(e.g., including a list, tile options, etc.) displayed on the userdevice of user 201. Authorization computer 212 may provide user 201options to select wallet providers that are supported for use with thenew card issued by the issuer associated with authorization computer212. In some embodiments, user 201 may already be enrolled with one ormore of the provided wallet providers. In other embodiments, user 201may not be enrolled with one or more of the provided wallet providers.

At step 8, user 201 may select a wallet provider from the optionsprovided by authorization computer 212. The selection may be indicatedby any suitable interaction with the user interface displayed on theuser device of user 201. For example, user 201 may confirm theirselection of the wallet provider by clicking on a software or hardwarebutton, inputting a voice command, or other suitable methods. While anexemplary case in which user 201 selects a single wallet provider isdescribed in flowchart 1000 for simplicity, in some embodiments, user201 may select multiple wallet providers from the provided options forwhich to utilize with the new card.

After user 201 selects the wallet provider, authorization computer 212may redirect user 201 to processor server computer 210, so that the newcard may be enrolled in the selected wallet provider. The redirectionmay be implemented in any suitable manner. For example, in oneimplementation, upon user 201 confirming their selection of the walletprovider, authorization computer 212 may redirect user 201 based on theaccess link provided by processor server computer 210 to authorizationcomputer 212 in step 5. In another implementation, authorizationcomputer 212 may embed the access link in a button clicked on by user201 to confirm the selection of the wallet provider. The access link maybe activated when the button is clicked by user 201, redirecting user201 to a website hosted by processor server computer 210.

Processor server computer 210 may display, to user 201 by their userdevice, information that will be utilized to enroll the new card withthe selected wallet provider. For example, the information may be userinformation and token information associated with the new card.Processor server computer 210 may request user 201 to validate theinformation before enrolling the new card with the wallet provider. Forexample, user 201 may check whether the displayed information isaccurate and then may confirm to that the information is valid. User 201may indicate the confirmation by clicking on a software or hardwarebutton, inputting a voice command, or other suitable methods. In someembodiments, user 201 may validate the information prior to selectingthe wallet provider.

At step 9, after user 201 validates the information, processor servercomputer 210 may send user information and token information to serviceprovider computer 214. Service provider computer 214 may be associatedwith the wallet provider selected by user 201 and that is supported bythe issuer associated with authorization computer 212. The userinformation and token information may be sent in any suitable manner,such as by an electronic message sent over a communications network.

At step 10, service provider computer 214 may store the receivedinformation in its local systems. Based on the received information,service provider computer 214 may determine whether user 201 has anexisting account with service provider computer 214. For example,service provider computer 214 may check whether any existing accountincluding the received user information (e.g., name, address, etc.) isstored in its systems.

At step 11, in some embodiments, service provider computer 214 maynotify processor server computer 210 that the received information wasstored. In some embodiments, service provider computer 214 may alsonotify whether user 201 has an existing account with service providercomputer 214.

At step 12, service provider computer 214 may prompt user 201 to providewallet provider account information. If service provider computer 214determines that user 201 does not have an existing account, serviceprovider computer 214 may prompt user 201 to create a new account. Forexample, service provider computer 214 may prompt user 201 to create anew username, password, and enter any other registration information(e.g., contact information) to generate the new account.

At step 13, in response to the prompt from service provider computer214, user 201 may enter the wallet provider account information. If user201 is creating a new account with service provider computer 214, user201 may enter a new username, password, and enter any other registrationinformation to generate the new account.

At step 14, service provider computer 214 may create a wallet provideraccount for user 201. The account may be associated with theregistration information entered by user 201. Further, service providercomputer 214 may link the new account to the token received by processorserver computer 210 and associated with the new card issued byauthorization computer 212. This can enable user 201 to utilize thenewly issued card with their wallet provider account.

In other embodiments, user 201 may already have an existing account withservice provider computer 214. In this case, at step 12, serviceprovider computer 214 may simply prompt user 201 for a registeredusername and password. Further at step 13, if user 201 already has anexisting account with service provider computer 214, user 201 may entertheir registered username and password into a user interface on theiruser device to log in to their existing account. At step 14, serviceprovider computer 214 may link the existing account to the tokenreceived by processor server computer 210 and associated with the newcard issued by authorization computer 212.

At step 15, user 201 may conduct the checkout process on the merchantwebsite using their newly issued card. User 201 may receive theadvertised discount on their transaction. Hence, user 201 may request anew card and immediately may be able to utilize the newly issued cardwith a digital wallet for the transaction.

While the embodiments above describe the user device of user 201 beingutilized for remote transactions (e.g., e-commerce transaction, onlinetransaction, etc.), embodiments are not so limited. For example,embodiments of the invention may be extended to transactions that areconducted at a physical POS terminal, in which a similar flow to that ofFIG. 10 may be utilized. After user 201 requests a new card, which isthen approved and linked to a digital wallet, user 201 may utilize thenew card at the POS terminal. For example, user 201 may pay for atransaction using their new card by a contactless transaction with anaccess device at a merchant. Hence, the user device of user 201 may beany suitable device that may be capable of conducting either type oftransaction.

As described above, in some embodiments, user 201 may select multiplewallet providers from the provided options for which to utilize with thenew card. In this case, for each service provider selected by user 201,processor server computer 210 may send user information and tokeninformation to a wallet provider computer associated with each selectedwallet provider. Additionally, each wallet provider computer thatreceives information from processor server computer 210 may performsteps 10-12, receive information from user 201 at step 13, and furtherperform step 14. Thus, the token associated with the newly issued cardmay be provisioned to multiple digital wallets of user 201, which may beimmediately available for use by user 201.

A concrete example of a case in which the steps of flowchart 1000 may beperformed is provided below. A user may be shopping at an online websiteof a merchant, where the website displays an advertisement that offers adiscount of 25% off of the user's transaction if the user utilized acard issued by issuer. The user may click the advertisement and applyfor a new card with the issuer, which may approve the user and send cardaccount information to a processor server computer. The processor servercomputer, which may also be a token service provider, may tokenize thecard (e.g., generate a new token) and send token information to theissuer computer associated with the issuer along with a link routed tothe token service of the token service provider. Subsequently, theissuer computer may send the user the link.

The token service may then validate the user and ask the user with whichwallet they would like to enroll. The user may select a wallet provider,such as Visa Checkout™, triggering the token service to send tokeninformation to a server associated with Visa Checkout™. The merchant mayaccept Visa Checkout™ transactions. The Visa Checkout™ server may thenprompt the user to create a new Visa Checkout™ account or log in to anexisting Visa Checkout™ account. Subsequently, the new token may beprovisioned to the user's Visa Checkout™ account. The user may thenconduct the transaction with the merchant using the newly issued cardaccount with Visa Checkout™ and receive the advertised 25% discount.

Another use case according to embodiments of the invention is describedbelow. A user may be at a mall and may see an advertisement to utilize acard issuer by a certain issuer for rewards (e.g., gaining loyaltypoints). The user may open a wallet provider application on their mobiledevice. The wallet provider application may allow the user to enrollwith issuers. Accordingly, the wallet provider application may collectuser information from the user and send it to the issuer computerassociated with the issuer indicated in the advertisement. The issuermay approve the user and send new account information to a processorserver computer, which may also be a token service provider. Theprocessor server computer may tokenize the card, and send a token backto the issuer computer. The issuer computer may send the token to thewallet provider and the wallet provider may provision the token on theuser's mobile device. The user can then utilize the mobile device for acheckout process with the advertised rewards applied. Hence, the cardmay be made available on the mobile device immediately after approval bythe issuer.

In some embodiments, tokenization of card account information may not beperformed. For example, in the case of flowchart 1000 of FIG. 10, steps3 through 6 may be omitted. In subsequent steps (e.g., step 9), anaccount number may be sent instead of a token. Even with the omission oftokenization, the user may still be able to utilize the newly issuedcard immediately after approval by the issuer. However, tokenization mayprovide security benefits, since a token may not be easily linked to anactual account, except by a token provider service.

A method according to the embodiments of the invention can be describedwith respect to FIG. 11. FIG. 11 shows a flowchart 1100 of a method forenabling a user immediate card access upon approval according toembodiments of the present invention and includes a user 301, a browser302, an authorization computer 312 associated with an authorizingentity, a processor server computer 310, and a service provider computer314. In some embodiments, processor server computer 310 may also be atoken service provider enabling a tokenization program. Anycommunications sent to and received from user 301 may be through a userdevice, such as user device 103 of FIG. 4. The user device may runbrowser 302. In some embodiments, processor server computer 310 may alsobe known as a payment processor server computer or payment processingnetwork, authorization computer 312 may also be known as an issuercomputer, and service provider computer 314 may also be known as aresource provider computer. In the exemplary case described below,service provider computer 314 may be a wallet provider computer.

At step 1, user 301 may activate a card. User 301 may enter user datainto their user device, which sends the entered user data toauthorization computer 312. Authorization computer 312 may approve user301 based on the entered information. If authorization computer 312approves user 301, authorization computer 312 may issue the new card touser 301. Authorization computer 312 may generate card information forthe new card requested by user 301. In some embodiments, the cardinformation may include an account identifier (e.g., account number),other account information (e.g., expiration date, CVV, etc.), andtransaction information that may be utilized for a transaction. Cardinformation may also be known as account information or card accountinformation.

At step 2, authorization computer 212 may enroll the user data in thetokenization program and by sending the user data and the cardinformation for the new card to processor server computer 210. The userdata may include cardholder information and cardholder contactinformation. In addition to the user data and card information,authorization computer 212 may send any additional future processinginstructions. An example of a future processing instruction may be aninstruction to not validate the consumer address when the consumercreates their account. The user data, card information, and additionalinstructions may be sent in any suitable manner, such as by anelectronic message sent over a communications network.

At step 3, processor server computer 310 may store the received userdata and card information and activate an account of user 301. Thereceived user data and card information may be stored in associationwith user 301, such as in a data record for the account of user 301.

At step 4, processor server computer 310 may enroll the new card in thetokenization program. Processor server computer 310 may generate a tokenand token identifier for the new card. A token identifier may be areference to a card account or token. In some embodiments, the tokenidentifier may be specific to a wallet provider or may be a genericidentifier that points to an account number. In some embodiments,processor server computer 310 may also generate card art for the newcard.

At step 5, processor server computer 310 may generate links to walletproviders (WP links). In some embodiments, the links may be customwallet provider links. The wallet providers for which processor servercomputer 310 generates links may be those which are supported byauthorization computer 312.

At step 6, processor server computer 310 may send a response toauthorization computer 312. The response may include the tokenidentifier, any generated links to wallet providers, card art and otherinformation helpful to authorization computer 312. In some embodiments,sending multiple wallet provider links may be optional.

At step 7, authorization computer 312 may deliver the token identifierand wallet provider links to user 301. In some embodiments, the walletprovider links may be provided in a user interface prompting user 301 tochoose a wallet provider corresponding to one of the provided walletprovider links.

At step 8, user 301 may access the selected link received fromauthorization computer 312. User 301 may be able to select a link byclicking the link or a software button with the embedded link. While acase in which a single link is selected is described in this flow, inother cases, user 301 may select more than one link. In someembodiments, the selected link may be associated with service providercomputer 314.

At step 9, in response to user 301 accessing the link, user 301 may bedirected to browser 302. Browser 302 may open a website or applicationhosted by service provider computer 314.

At step 10, user 301 may visit the website or application hosted byservice provider computer 314. At the backend, browser 302 may requestany information utilized to run the website or application from serviceprovider computer 314. For example, the information may include userinterface components, instructions, or other information.

At step 11, service provider computer 314 may return the requestedinformation to browser 302. This may enable browser 302 to display anappropriate page, such as a log in page, to user 301.

At step 12, user 301 may be prompted to log in to their account withservice provider computer 314 by browser 302. User 301 may enterverification attributes into the user interface displayed by browser302. The verification attributes may include a username, password, andthe token identifier, which may then be transmitted to service providercomputer 314 at step 13.

At step 14, service provider computer 314 may call processor servercomputer 310 to pull user data associated with user 301 and the newlyissued card. For example, processor server computer 310 may openApplication Programming Interfaces (APIs) to enable service providercomputer 314 to pull data, which may include cardholder information,payment account information, and cardholder contact information. In someembodiments, service provider computer 314 may utilize the APIs torequest processor server computer 310 to retrieve certain data. Forexample, service provider computer 314 may provide the token identifierto processor server computer 310 and request from processor servercomputer 310 the token associated with the account of user 301. Thus,instead of processor server computer 310 pushing data to serviceprovider computer 314, such as described in FIG. 10, flowchart 1100shows service provider computer 314 calling APIs of processor servercomputer 310 to obtain information.

At step 15, processor server computer 310 may retrieve the tokenassociated with the account of user 301 stored in its systems. Processorserver computer 310 may send the retrieved token, cardholderinformation, payment account information, and cardholder contactinformation to service provider computer 314 at step 16.

At step 17, service provider computer 314 may enable the user to log into their wallet provider account. Service provider computer 314 maystore the information retrieved in steps 14 through 16, includingcardholder information, payment account information, cardholder contactinformation, and token information, in association with the account ofuser 301.

At step 18, service provider computer 314 may display a notification tobrowser 302 that user 301 may utilize their new card with their walletprovider account associated with service provider computer 314. This mayindicate that the token associated with the newly issued card isprovisioned such that user 301 may utilize their new card for subsequenttransactions.

A method according to the embodiments of the invention can be describedwith respect to FIG. 12. FIG. 12 shows a flowchart 1200 of a method forenabling a user immediate card access upon approval according toembodiments of the present invention and includes a user 401, a browser402, an authorization computer 412 associated with an authorizingentity, a processor server computer 410, and a service provider computer414. In some embodiments, processor server computer 410 may also be atoken service provider enabling a tokenization program. Anycommunications sent to and received from user 401 may be through a userdevice, such as user device 103 of FIG. 4. The user device may runbrowser 402. In some embodiments, processor server computer 410 may alsobe known as a payment processor server computer or payment processingnetwork, authorization computer 412 may also be known as an issuercomputer, and service provider computer 414 may also be known as aresource provider computer. In the exemplary case described below,service provider computer 414 may be a wallet provider computer.

Steps 1 through 11 in flowchart 1200 may be similar to correspondingsteps 1 through 11 described in flowchart 1100 of FIG. 11. Thus, steps 1through 11 are not being included in the description of flowchart 1200herein so that information is not repeated. However, it is understoodthat the description corresponding to steps 1 through 11 in flowchart1100 may be incorporated into the description of flowchart 1200 of FIG.12.

At step 12, browser 402 may have open a website or application hosted byservice provider computer 414. Browser 402 may render user 401 to signup for an account with service provider computer 414 or sign in with analready existing account.

Accordingly, at step 13, if user 401 does not yet have an account withservice provider computer 414, user 401 may create a username andpassword and provide any additional verification data requested byservice provider computer 414. If user 401 already has an account withservice provider computer 414, then user 401 may enter their registeredusername and password and any additional verification data requested byservice provider computer 414 to enter their existing account. Theadditional verification data may include a token identifier associatedwith their new card account.

At step 14, service provider computer 414 may call processor servercomputer 310 to pull user data associated with user 401 and the newlyissued card. For example, processor server computer 410 may openApplication Programming Interfaces (APIs) to enable service providercomputer 414 to pull data, which may include cardholder information,payment account information, and cardholder contact information. In someembodiments, service provider computer 414 may utilize the APIs torequest processor server computer 410 to retrieve certain data. Forexample, service provider computer 414 may provide the token identifierto processor server computer 410 and request from processor servercomputer 410 the token associated with the account of user 401. Thus,instead of processor server computer 410 pushing data to serviceprovider computer 414, such as described in FIG. 10, flowchart 1200shows service provider computer 414 calling APIs of processor servercomputer 410 to obtain information.

At step 15, processor server computer 410 may send cardholderinformation, payment account information, and cardholder contactinformation to service provider computer 414. Subsequently, at step 16,service provider computer 414 may save the received user data in a datarecord for the wallet provider account of user 401.

At step 17, service provider computer 414 may send a payload includingthe user data to a user interface displayed on browser 402 forconfirmation by user 401. For example, service provider computer 414 maysend web page form filled with user data associated with user 401. Theform may display the user data in the user interface in editable fields,so that use 401 may change any values if desired.

At step 18, user 401 may view the data sent by service provider computer414 and update or confirm the data. User 401 may update any data byediting the fields in the user interface. When finished editing, or ifno edits are needed, user 401 may confirm the data is accurate byclicking on a button on browser 402. Subsequently, at 19, browser 402may send an indication that user 401 confirmed the data of the walletprovider account to service provider computer 414. By allowing user 401to confirm the data, service provider computer 414 ensures accuracy ofdata while forgoing the need for user 401 to input all the user data,which can be time consuming and cumbersome.

At step 20, service provider computer 414 may link the payload data tothe wallet provider account of user 401. For example, service providercomputer 414 may store the payload data in association with any otherinformation related to the wallet provider account of user 401.

At step 21, service provider computer 414 may display a notification tobrowser 402 that user 401 may utilize their new card with their walletprovider account associated with service provider computer 414. This mayindicate that the token associated with the newly issued card isprovisioned such that user 401 may utilize their new card for subsequenttransactions.

Embodiments of the invention may provide a number of advantages. Forexample, embodiments of the invention increase efficiency as a user nolonger needs to wait to receive a plastic card in order to utilize a newcard account and can have a new card immediately available, with minimaluser input, on their mobile device once approved by an issuer. Thisforgoes the need for the user to manually add the new card to multipledigital wallets before use. This is in contrast to conventional systems,in which manual addition of the new card to a digital wallet disruptsuser experience during a transaction, such as a checkout process.

Further, embodiments of the invention enable issuing a new card that canbe utilized with a mobile wallet that was not yet installed on themobile device when the card was issued. In other words, a digital walletprovider can be chosen after the new card is issued. This allows theuser to easily utilize the issued card without the need for a previouslyinstalled mobile wallet that must be compatible with the issuer. This isconvenient because the user may not know which digital wallets arecompatible with the issuer before the new card is issued. Since the useris provided wallet provider options by the issuer computer, thisprovides the user the flexibility to choose amongst a plurality ofwallet providers that may have different benefits. In addition,integrating tokenization processes with embodiments of the inventionenables increased efficiency without compromising security of atransaction.

A computer system may be utilized to implement any of the entities orcomponents described above. Subsystems of the computer system may beinterconnected via a system bus. Additional subsystems may include aprinter, a keyboard, a fixed disk (or other memory comprising computerreadable media), a monitor, which is coupled to a display adapter, andothers. Peripherals and input/output (I/O) devices, which couple to anI/O controller (which can be a processor or other suitable controller),can be connected to the computer system by any number of means known inthe art, such as by a serial port. For example, the serial port orexternal interface can be used to connect the computer apparatus to awide area network such as the Internet, a mouse input device, or ascanner. The interconnection via system bus allows the central processorto communicate with each subsystem and to control the execution ofinstructions from system memory or the fixed disk, as well as theexchange of information between subsystems. The system memory and/or thefixed disk may embody a computer readable medium. In some embodiments,the monitor may be a touch sensitive display screen.

A computer system can include a plurality of the same components orsubsystems, e.g., connected together by external interface or by aninternal interface. In some embodiments, computer systems, subsystem, orapparatuses can communicate over a network. In such instances, onecomputer can be considered a client and another computer a server, whereeach can be part of a same computer system. A client and a server caneach include multiple systems, subsystems, or components.

It should be understood that any of the embodiments of the presentinvention can be implemented in the form of control logic using hardware(e.g. an application specific integrated circuit or field programmablegate array) and/or using computer software with a generally programmableprocessor in a modular or integrated manner. As used herein, a processorincludes a single-core processor, multi-core processor on a sameintegrated chip, or multiple processing units on a single circuit boardor networked. Based on the disclosure and teachings provided herein, aperson of ordinary skill in the art will know and appreciate other waysand/or methods to implement embodiments of the present invention usinghardware and a combination of hardware and software.

Any of the software components or functions described in thisapplication may be implemented as software code to be executed by aprocessor using any suitable computer language such as, for example,Java, C, C++, C#, Objective-C, Swift, or scripting language such as Perlor Python using, for example, conventional or object-orientedtechniques. The software code may be stored as a series of instructionsor commands on a computer readable medium for storage and/ortransmission, suitable media include random access memory (RAM), a readonly memory (ROM), a magnetic medium such as a hard-drive or a floppydisk, or an optical medium such as a compact disk (CD) or DVD (digitalversatile disk), flash memory, and the like. The computer readablemedium may be any combination of such storage or transmission devices.

Such programs may also be encoded and transmitted using carrier signalsadapted for transmission via wired, optical, and/or wireless networksconforming to a variety of protocols, including the Internet. As such, acomputer readable medium according to an embodiment of the presentinvention may be created using a data signal encoded with such programs.Computer readable media encoded with the program code may be packagedwith a compatible device or provided separately from other devices(e.g., via Internet download). Any such computer readable medium mayreside on or within a single computer product (e.g. a hard drive, a CD,or an entire computer system), and may be present on or within differentcomputer products within a system or network. A computer system mayinclude a monitor, printer, or other suitable display for providing anyof the results mentioned herein to a user.

The above description is illustrative and is not restrictive. Manyvariations of the invention will become apparent to those skilled in theart upon review of the disclosure. The scope of the invention should,therefore, be determined not with reference to the above description,but instead should be determined with reference to the pending claimsalong with their full scope or equivalents.

One or more features from any embodiment may be combined with one ormore features of any other embodiment without departing from the scopeof the invention.

A recitation of “a”, “an” or “the” is intended to mean “one or more”unless specifically indicated to the contrary.

All patents, patent applications, publications, and descriptionsmentioned above are herein incorporated by reference in their entiretyfor all purposes. None is admitted to be prior art.

What is claimed:
 1. A method, comprising performing, by a servercomputer: sending, to an authorization computer, a list of participatingresource providing entities, wherein the authorization computer promptsa user operating a user device to make a selection from the list ofparticipating resource providing entities; receiving a selection of oneor more resource providing entities from the participating resourceproviding entities; receiving a request to issue tokens associated withan account of the user for the one or more resource providing entities;and for each of the one or more resource providing entities: determininga token associated with the account of the user; and sending the tokento a resource providing entity computer associated with the resourceproviding entity, wherein the user conducts a transaction with theresource providing entity using the token.
 2. The method of claim 1,further comprising: determining an authentication method supported bythe authorization computer; for each of the list of participatingresource providing entities: determining an authentication methodsupported by the participating resource providing entity; comparing theauthentication method supported by the participating resource providingentity and the authentication method supported by the authorizationcomputer; upon determining that the compared authentication methodsmatch, including the participating resource providing entity in the listof participating resource providing entities.
 3. The method of claim 2,further comprising: determining that at least one of the participatingresource providing entities has an account on file for the user; andsending, to the authorization computer, information indicating the atleast one participating resource providing entity with which the userhas the account on file.
 4. The method of claim 3, wherein the selectionof the one or more resource providing entities by the user includes aparticipating resource providing entity that has an account on file forthe user, and wherein the user conducts the transaction using theaccount on file.
 5. The method of claim 1, further comprising:generating a link routed to the server computer; and sending the link tothe authorization computer, wherein the user activates the link usingthe user device after the authorization computer prompts the user. 6.The method of claim 5, further comprising: for each of the plurality ofparticipating resource providing entities selected by the user:prompting the user for authentication information for the participatingresource providing entity; and sending the authentication information tothe participating resource providing entity.
 7. The method of claim 6,wherein the authentication information is utilized to generate a newaccount for the user associated with the participating resourceproviding entity.
 8. The method of claim 1, further comprising:generating a plurality of links routed to the plurality of resourceproviding entities; and sending the plurality of links to theauthorization computer, wherein the user activates the plurality oflinks using the user device after the authorization computer prompts theuser.
 9. The method of claim 1, wherein the account is a new account,further comprising: receiving, from the authorization computer, accountinformation associated with the account.
 10. The method of claim 1,wherein the account is an existing account, further comprising:retrieving account information associated with the account.
 11. A servercomputer comprising: a processor; and a computer readable medium coupledto the processor, the computer readable medium comprising codeexecutable to perform a method comprising: sending, to an authorizationcomputer, a list of participating resource providing entities, whereinthe authorization computer prompts a user operating a user device tomake a selection from the list of participating resource providingentities; receiving a selection of one or more resource providingentities from the participating resource providing entities; receiving arequest to issue tokens associated with an account of the user for theone or more resource providing entities; and for each of the one or moreresource providing entities: determining a token associated with theaccount of the user; and sending the token to a resource providingentity computer associated with the resource providing entity, whereinthe user conducts a transaction with the resource providing entity usingthe token.
 12. The server computer of claim 11, the method furthercomprising: determining an authentication method supported by theauthorization computer; for each of the list of participating resourceproviding entities: determining an authentication method supported bythe participating resource providing entity; comparing theauthentication method supported by the participating resource providingentity and the authentication method supported by the authorizationcomputer; upon determining that the compared authentication methodsmatch, including the participating resource providing entity in the listof participating resource providing entities.
 13. The server computer ofclaim 12, the method further comprising: determining that at least oneof the participating resource providing entities has an account on filefor the user; and sending, to the authorization computer, informationindicating the at least one participating resource providing entity withwhich the user has the account on file.
 14. The server computer of claim13, wherein the selection of the one or more resource providing entitiesby the user includes a participating resource providing entity that hasan account on file for the user, and wherein the user conducts thetransaction using the account on file.
 15. The server computer of claim11, the method further comprising: generating a link routed to theserver computer; and sending the link to the authorization computer,wherein the user activates the link using the user device after theauthorization computer prompts the user.
 16. The server computer ofclaim 15, the method further comprising: for each of the plurality ofparticipating resource providing entities selected by the user:prompting the user for authentication information for the participatingresource providing entity; and sending the authentication information tothe participating resource providing entity.
 17. The server computer ofclaim 16, wherein the authentication information is utilized to generatea new account for the user associated with the participating resourceproviding entity.
 18. The server computer of claim 11, the methodfurther comprising: generating a plurality of links routed to theplurality of resource providing entities; and sending the plurality oflinks to the authorization computer, wherein the user activates theplurality of links using the user device after the authorizationcomputer prompts the user.
 19. The server computer of claim 11, whereinthe account is a new account, the method further comprising: receiving,from the authorization computer, account information associated with theaccount.
 20. The server computer of claim 11, wherein the account is anexisting account, the method further comprising: retrieving accountinformation associated with the account.